1. Can houdini.env live anywhere else but in $HOME? Jeff W. suggests that you can put it anywhere in this post:
https://www.sidefx.com/forum/topic/13416/#post-63585 [sidefx.com]
But it seems as though the only one Houdini reads is the one in $HOME. Even if it can't find one in $HOME it will make a template one.
2. Can you change HOUDINI_PATH or OTL_SCAN_PATH in 456.cmd after you've double-clicked a .hip file and expect that any new OTLs/HDAs that you add to either path in 456.cmd will be scanned automatically in that session? Or is it too late at that point i.e. those particular env vars need to be set prior to launching?
I am trying to find a mechanism for when a user double clicks a .hip file in a given $JOB such that the specific versions of Arnold and Redshift are loaded associated with that $JOB. Simplest method I can see is if there is a houdini.env sitting in each $JOB (as Jeff suggests) but this doesn't seem to work.
Found 11 posts.
Search results Show results as topic list.
Technical Discussion » Switching Scanned OTLs Based on $JOB via Env Vars?
- Julian Johnson
- 11 posts
- Offline
SI Users » How to get polygon vectors
- Julian Johnson
- 11 posts
- Offline
owlYzarc - thanks for pointing that out. It couldn't be more wrong! :-) Back to the drawing board with ForEach. @Chris - apologies for wasting your time on that one!
SI Users » How to get polygon vectors
- Julian Johnson
- 11 posts
- Offline
Hi Chris,
I should have been more accurate in my description of what I was doing. As I understand it, all Partition does is create an independent group for each polygon. The magic happens in the ForEach node. Here it iterates over each group (in this case each polygon) and as it is iterating it treats each polygon as an individual (non-attached) item i.e. each polygon only has four vertices numbered 0,1,2,3. It somehow ignores the overall point numbering from the grid itself and treats the quad as solo entity which is why referencing points 0 to 1 and 0 to 2 works consistently in the expression. All partition does is split your geometry into groups based on patterns etc. At the end of the ForEach cycle the geometry is merged back together and the original point order restored…..at least, that's how I think it works!
I should have been more accurate in my description of what I was doing. As I understand it, all Partition does is create an independent group for each polygon. The magic happens in the ForEach node. Here it iterates over each group (in this case each polygon) and as it is iterating it treats each polygon as an individual (non-attached) item i.e. each polygon only has four vertices numbered 0,1,2,3. It somehow ignores the overall point numbering from the grid itself and treats the quad as solo entity which is why referencing points 0 to 1 and 0 to 2 works consistently in the expression. All partition does is split your geometry into groups based on patterns etc. At the end of the ForEach cycle the geometry is merged back together and the original point order restored…..at least, that's how I think it works!
SI Users » How to get polygon vectors
- Julian Johnson
- 11 posts
- Offline
Chris,
This is probably over-elaborate but if you partition your quad grid first you'll get independent quads which might have the same point order. From there you can foreach with an expression and construct your axes. Works in this simple scene but I don't know whether it's a universal solution i.e. I don't know what dictates the point order of the partitioned quads or whether you're going to run into the same anomalies although a sort after the each node for each poly might just fix it…
This is probably over-elaborate but if you partition your quad grid first you'll get independent quads which might have the same point order. From there you can foreach with an expression and construct your axes. Works in this simple scene but I don't know whether it's a universal solution i.e. I don't know what dictates the point order of the partitioned quads or whether you're going to run into the same anomalies although a sort after the each node for each poly might just fix it…
SI Users » Translating ICE Roll Object Scene to Houdini
- Julian Johnson
- 11 posts
- Offline
Hi owlYzarc - that's such a great tip and .hip :-) Got to start thinking in Houdini's own terms.
SI Users » Translating ICE Roll Object Scene to Houdini
- Julian Johnson
- 11 posts
- Offline
SI Users » Translating ICE Roll Object Scene to Houdini
- Julian Johnson
- 11 posts
- Offline
SI Users » Translating ICE Roll Object Scene to Houdini
- Julian Johnson
- 11 posts
- Offline
Hi Imre - thanks for the advice. I'll definitely look at the SOP solver. As far as retaining the previous frame's state in ICE goes it's just a question of whether your ICE tree sits in the simulation stack or below it. Anything queried from ICE in the simulation stack (in fact any operator in there) retains it's state from the previous frame.
I can't imagine being anywhere near confident enough to commit to using Houdini in production shots until I can clearly see how to get from A to B. At the moment, I'm not even sure I can see where A is!
I can't imagine being anywhere near confident enough to commit to using Houdini in production shots until I can clearly see how to get from A to B. At the moment, I'm not even sure I can see where A is!
SI Users » Translating ICE Roll Object Scene to Houdini
- Julian Johnson
- 11 posts
- Offline
SI Users » Recreating ICE's "Modulate by Null"
- Julian Johnson
- 11 posts
- Offline
Really useful to see the direct comparison with the ICE tree. I didn't know you could drag and drop expressions which starts to make it easier already. Great stuff.
SI Users » Translating ICE Roll Object Scene to Houdini
- Julian Johnson
- 11 posts
- Offline
As my first Houdini project I've been trying to convert an ICE rig I did for rolling an irregular shaped object along a ground plane. The original is here:
https://vimeo.com/4662525 [vimeo.com]
and the Houdini .hipnc scene is attached.
Although I now have ‘working’ versions in Houdini it's thrown up a ton of questions and conceptual misunderstandings. It's also far from optimal. I thought I'd try and document them as much as I could to illustrate where things got confusing and in the hope that someone might point me in the right direction on some of those issues! The .hipnc file contains stickies illustrating specific problems, too. I apologise for the length in advance…
The most significant problem I've found is the transition away from a single monolithic ICE tree to multiple networks in Houdini. That's not to say that in Softimage there was no communication between different ICE trees but you could do an enormous amount in a single one. The ICE tree is like a loosely-typed visual programming container that could perform multiple types of calculations - point based, poly based, node(UV) based, singletons, arrays etc. By the very fact it is one tree the problems of hooking pieces of data together were largely overcome.The ease with which you can creatively piece together different data elements makes it both usable and artist friendly. That whole process is aided by the simplicity of the Get Data and Set Data mechanisms. It is a doddle to pull data into the tree and set data at any point during its execution. This mixture of data types and calcuation types in a single tree doesn't impact the parallel execution speed which is intelligent enough to apply itself when the data/calculation is valid for parallelisation.
The best example I can give of this is the problem of feeding the global transform of a driver object into a VOP SOP in my roll object scene. In ICE this is simply a question of dragging the Global Transform into the simulated ICE tree. Each frame I can store the old transform and then compare it to the new. Very simple. In Houdini, however, it seems more complex - possibly because I haven't found the best way yet. Certainly there are a lot more choices involved. In the end I constructed three different networks to try each method I found - using chf() to create a translation attribute for the driver null; using a chops to derive the translation vector and length; and finally using an inline vex node with optransform to pull the data directly into the VOP (most ICE like but I couldn't figure out a way to store the matrix for reuse on the next frame). But, even in the simplest of those scenarios (i.e. the inline VEX node it wasn't particularly obvious how to do that!)
All these scenarios involved writing some kind of expression and I fully understand this is why Houdini is so powerful but it is something of a culture shock after the simplicity of ICE.
Given the fundamental requirement to pass data from one network of nodes to another I wonder if some of the simplicity of the Get Data/Set Data mechanism could be applied - something that intercedes and lets you visually pick or drag and drop appropriate inputs and that's also contextually aware of what's permissable. Again, I'm a total newbie so this may well all slot into place after months of usage!
As others have pointed out in posts on this forum the ability to get a quick min, max, average of a pointset is a fantastic feature in ICE, a real time saver - I really wanted a node in the VOP to get the lowest y value of all the points after they had been rotated and it seems clunky to have exit the VOP to promote and demote the attribute to do so.Similarly, the visualisation tools in ICE for attributes are exceptional and seemingly much more accessible than those in Houdini.
In the end, however, I'm blown away by how powerful Houdini is and can see how it's like ICE on steroids. Learning where to get data from, how to get it and, more importantly, where and how you should perform the actual calculations is presumably the ‘normal’ Houdini learning process.
If anyone does have a chance to look at the .hipnc scene and comment on any of the craziness in there it would be greatly appreciated.
Julian
Glassworks
https://vimeo.com/4662525 [vimeo.com]
and the Houdini .hipnc scene is attached.
Although I now have ‘working’ versions in Houdini it's thrown up a ton of questions and conceptual misunderstandings. It's also far from optimal. I thought I'd try and document them as much as I could to illustrate where things got confusing and in the hope that someone might point me in the right direction on some of those issues! The .hipnc file contains stickies illustrating specific problems, too. I apologise for the length in advance…
The most significant problem I've found is the transition away from a single monolithic ICE tree to multiple networks in Houdini. That's not to say that in Softimage there was no communication between different ICE trees but you could do an enormous amount in a single one. The ICE tree is like a loosely-typed visual programming container that could perform multiple types of calculations - point based, poly based, node(UV) based, singletons, arrays etc. By the very fact it is one tree the problems of hooking pieces of data together were largely overcome.The ease with which you can creatively piece together different data elements makes it both usable and artist friendly. That whole process is aided by the simplicity of the Get Data and Set Data mechanisms. It is a doddle to pull data into the tree and set data at any point during its execution. This mixture of data types and calcuation types in a single tree doesn't impact the parallel execution speed which is intelligent enough to apply itself when the data/calculation is valid for parallelisation.
The best example I can give of this is the problem of feeding the global transform of a driver object into a VOP SOP in my roll object scene. In ICE this is simply a question of dragging the Global Transform into the simulated ICE tree. Each frame I can store the old transform and then compare it to the new. Very simple. In Houdini, however, it seems more complex - possibly because I haven't found the best way yet. Certainly there are a lot more choices involved. In the end I constructed three different networks to try each method I found - using chf() to create a translation attribute for the driver null; using a chops to derive the translation vector and length; and finally using an inline vex node with optransform to pull the data directly into the VOP (most ICE like but I couldn't figure out a way to store the matrix for reuse on the next frame). But, even in the simplest of those scenarios (i.e. the inline VEX node it wasn't particularly obvious how to do that!)
All these scenarios involved writing some kind of expression and I fully understand this is why Houdini is so powerful but it is something of a culture shock after the simplicity of ICE.
Given the fundamental requirement to pass data from one network of nodes to another I wonder if some of the simplicity of the Get Data/Set Data mechanism could be applied - something that intercedes and lets you visually pick or drag and drop appropriate inputs and that's also contextually aware of what's permissable. Again, I'm a total newbie so this may well all slot into place after months of usage!
As others have pointed out in posts on this forum the ability to get a quick min, max, average of a pointset is a fantastic feature in ICE, a real time saver - I really wanted a node in the VOP to get the lowest y value of all the points after they had been rotated and it seems clunky to have exit the VOP to promote and demote the attribute to do so.Similarly, the visualisation tools in ICE for attributes are exceptional and seemingly much more accessible than those in Houdini.
In the end, however, I'm blown away by how powerful Houdini is and can see how it's like ICE on steroids. Learning where to get data from, how to get it and, more importantly, where and how you should perform the actual calculations is presumably the ‘normal’ Houdini learning process.
If anyone does have a chance to look at the .hipnc scene and comment on any of the craziness in there it would be greatly appreciated.
Julian
Glassworks
-
- Quick Links